The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:                3GPP third generation partnership project        DL downlink        EPS evolved packet system        EUTRAN evolved UTRAN        GPRS general packet radio service        IMS Internet protocol multimedia subsystem        PDN packet data network        PDP packet data protocol        PS packet switched (domain)        QCI quality class indicator        RAT radio access technology        RR radio resource        RRC radio resource control        UE user equipment        UL uplink        UTRAN universal terrestrial radio access network        VoIP voice over Internet protocol        
IMS services such as IMS VoIP use a PS domain bearer for PS connectivity in the serving network. IMS voice emergency sessions also use PS domain bearers (see 3GPP TS 23.060 v10.5.0 and 3GPP TS 23.401 v10.5.0). The PS domain provides the bearer as PDN connections that consist of one or more contexts as detailed at 3GPP TS 23.401 v10.5.0. “Contexts” in the GPRS radio access technology refers to PDP contexts, and in the EPS radio access technology refers to EPS bearer contexts. 3GPP TS 24.008 v10.4.0 and 3GPP TS 24.301 v10.4.0 detail that the UE may support a maximum of 11 simultaneous contexts. This is the maximum allowed by the 3GPP system and different UE models and manufacturers may support less than the maximum 11 contexts. For example, EUTRAN category 3 devices require only eight contexts. Certain other implementation reasons may leave a UE with the capacity to support only a maximum of six contexts, though in practice some widely deployed UEs support up to five contexts, many networks support only three and it appears that at least one mobile device operating system is limited to supporting only one context for its host UE.
In practice, it is possible that any given UE has PS domain bearers established for other purposes at the time the UE sees the need to establish PS emergency bearer services. In normal operation an IMS VoIP capable UE may have several contexts established; IMS VoIP itself reserves one context for signaling purposes that is used for registering to the IMS and also to establish normal (non-emergency) sessions. Then the UE may also have an additional PDN connection.
The PDN need not support IP dual stack (IPv4 and IPv6), in which case the PDN supporting both IP versions instructs the UE to establish separate PDN connections; one for IPv4 traffic and one for IPv6 traffic (see 3GPP TS 24.008 v10.4.0 and 3GPP TS 24.301 v10.4.0; these specifications use the term should instead of may for the network ‘instructing’ summarized above). This network configuration can double the number of active contexts that the UE must handle in parallel.
Regardless of the number of simultaneous contexts supported by the UE and the capabilities of the UE and the network to support (or not) dual stack bearers and different IP versions, it is possible that at a given time for a given UE the maximum number of contexts have already been activated for other purposes at the time of emergency VoIP voice call establishment. The UE will detect that it does not have enough resources to proceed with PS emergency bearer establishment due to too many active contexts.
A typical network configuration would still allow emergency access via so called Access Class 10 for a UE whose access for other services is barred (see 3GPP TS 22.011 v11.1.0 clause 4.4). Access Class 10 is broadcast in system information and informs UEs in the cell whether they are allowed to initiate an emergency call regardless of their access class barring status, so this allows the UE to establish an emergency call. Context deactivation is a normal priority procedure and subject to barring, so if the UE already has got its maximum number of active contexts, it is not allowed to deactivate PDP contexts in GPRS or to disconnect the PDN in EPS in order to relieve the necessary resources for the subsequent emergency call that would be allowed in this situation. But IMS emergency services are not yet deployed in real networks and devices, and so these problems related to establishing them have not yet been encountered in practice. Below is a review of relevant procedures for emergency services in GPRS and EPS networks.
There is an option already specified for a UE to use a PS attach procedure for emergency purposes, but this is restricted to a strictly limited service case when the UE cannot attach to the network for any other than emergency services (see 3GPP TS 24.008 v10.4.0 and 3GPP 24.301 v10.4.0). Those same specifications detail a service request procedure for a UE to initiate new services that has already successfully attached to the network. The GPRS service request contains PDP context status for the purpose of synchronizing the PDP context status between the UE and the network, if for some reason re-synchronizing is necessary.
If the UE has run out of EPS bearer contexts or GPRS PDP contexts, then it is allowed (per 3GPP TS 24.008 v10.4.0 and 3GPP 24.301 v10.4.0) to relieve either some or all of those resources by means of a UE-initiated EPS PDN disconnect procedure or a PDP context deactivation in GPRS and then establish the connectivity that is required for a PS emergency call. There are two shortfalls with this prior art approach: a) it imposes a long delay to establish an emergency call, and b) it may not be possible if the UE's Access Class is barred per clause 4 of 3GPP TS 22.011 v11.1.0.
So in current practice emergency calls can override several obstacles that would otherwise deny the UEs right for uplink access, such as if the UE is in limited service and is not able to attach for normal service or having a network assigned back-off timer miming. But if the UEs access to the network is barred, the UE-initiated deactivation of PDP contexts in GPRS and the UE-requested PDN disconnect procedure in EPS are forbidden. The UE would be allowed to establish an emergency call, but cannot do so since the procedures to relieve the resources that are essentially required for setting up the emergency call are normal priority procedures with no possibility to indicate “emergency” use. See 3GPP TS 44.018 clause 3.3.1.1.1; 3GPP TS 36.331 clause 5.3.3 and 3GPP TS 25.331 clause 8.1.8.
What is needed in the art is a way to assure a UE which needs to establish emergency services may do so under any conditions so long as the UE has sufficient signal strength with the network, and without undue delay given the emergency nature of the call.